Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000142_owner-urn-ietf _Thu Oct 31 14:40:51 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18482 for urn-ietf-out; Thu, 31 Oct 1996 14:40:51 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18470 for <[e-mail]>; Thu, 31 Oct 1996 14:40:46 -0500
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA27470  (mail destined for [e-mail]); Thu, 31 Oct 96 14:40:43 -0500
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA06593; Thu, 31 Oct 1996 12:40:39 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 31 Oct 1996 12:48:25 -0700
To: "Gregory J. Woodhouse" <[e-mail]>,
        Fisher Mark <[e-mail]>
From: Ron Daniel <[e-mail]>
Subject: RE: [URN] HTTP resolution protocol
Cc: "[e-mail]" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke Gregory J. Woodhouse (at least at 11:10 AM 10/31/96 -0800)

>It seems to me that we should follow the same model as other requests and
>use the status code to indicate a(n) (un)successful resolution and then use
>the entity-body to provide either explanatory text or hyperlinks for old
>browsers.

For the most part, this is what I intended. I need to be more explicit on
the Status codes that can be returned from successful or unsuccessful
resolution attempts.

One place where we seem to differ slightly is on the entity-body.
I certainly think that it should be used most of the time. The one place
where I think we should make an exception is the N2L request. If the
new URL is returned in the Location: header, clients will automatically
fetch the resource. If it is returned in the body, we get into the "click
twice to access" model, which is a real pain in the rear.

I will try to be more explicit on the various Status codes that should
be returned.


>Status 303 See Other seems a natural for our purposes--at least
>N2L resoulution.

Agreed, but it doesn't appear in my copy of RFC 1945 - the HTTP/1.0
spec. It is in the 1.1 spec, which is why I said it should be returned
there.

>For N2R resolution it would seem desirable to return the
>entire resource in the entity-body,

That is my intent, but I suppose I can try to tighten up my wording.
"standard HTTP mechanisms" was used to cover all the Content-type,
Status, ... material.

> and for N2Rs, I'd like to see a
>multipart/mixed or multipart/alternative entity containing each resource.

Right. Here again I should be more precise. I said "multipart", I think
"multipart/alternative" is probably the way to go.

>Here, I'm a little unsure as to the best status code. One possibility is
>200 OK for N2R, but I don't know about N2Rs.

I think that as long as at least one version of a resource can be returned,
200 OK is the way to go for both N2R and N2Rs.  There is the case to consider
where we ask N2Rs but only one resource can be returned. Do we need
to wrap it in a multipart even though there is only one part? I think not
but don't have strong feelings on the subject.


>Another question I have is
>whether there should be any indication tht the content was returned as a
>result of URN resolution. If so, a new status code may be necessary.

Is there any need to make such a distinction?
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"